home *** CD-ROM | disk | FTP | other *** search
/ STraTOS 1997 April & May / STraTOS 1 - 1997 April & May.iso / CD01 / INTERNET / SITES / RAND / ALL95.LZH / transcript_1128 / text0012.txt < prev    next >
Encoding:
Text File  |  1995-12-18  |  4.1 KB  |  152 lines
  1.  
  2.  
  3.  >> Newsflash: HERETIC SHAREWARE .WAD 
  4. works!!!!!!!!
  5.  
  6.  d> 
  7. :-)
  8.  
  9. I just tried a Doom2 IWAD - it worked too! 
  10. :)))))
  11.  
  12.  >> > So lets start do some serious coding!!!!!!!!!!!!!!!! 
  13. :-
  14.  
  15. I thought we already had been? I'm wrecked! 
  16. :))))
  17.  
  18.  >> Whats next on the list of 'to do'? T-mapping? (from someone who 
  19. knows
  20.  >> too little about 3D to be much 
  21. help...)
  22.  
  23. Yes, but there are some program-flow considerations to be dealt with before 
  24. we go near that - bottlenecks and so on. I really want to get NodeInCone 
  25. and some of the other nonsense into the DSP (along with AddWall & 
  26. ScanOcclusion which are already on the DSP). I think NodeInCone & the 3D 
  27. stuff are now beginning to have a reasonable impact on things since AddWall 
  28. was commited to DSP - AddWall used to be one of the time-eaters, but it's 
  29. now almost invisible timewise. Getting the wall/floor-runs back from the 
  30. DSP is the other bottleneck, but it's not so bad as I 
  31. expected.
  32.  
  33. There are still many speed improvements to be made before the 
  34. texturemapping should be attempted - it will be too hard to make changes 
  35. once its in there, so keeping it back until the program is correctly 
  36. organised is a good 
  37. idea.
  38.  
  39.  d> If I've understood matters correctly, Doug Little has moved on to 
  40. DSP
  41.  d> things for now. I believe he's mentioned that he'll look into 
  42. the
  43.  d> texture mapping after that. So, for the time being I think the rest 
  44. of
  45.  d> us should stay out of those 
  46. areas.
  47.  
  48. I'll get onto the texturemapping after the DSP 3D stuff is 
  49. sorted.
  50.  
  51.  d> There's a lot to BAD MOOD besides the graphics, 
  52. though.
  53.  
  54. Yes - a 
  55. lot.
  56.  
  57.  d> Some things to work on (or think 
  58. about):
  59.  
  60. d>
  61.  d> - 
  62. sound
  63.  d> Sound effects are of course needed, but should they perhaps be 
  64. 2D?
  65.  
  66. I think distance-based volume will do nicely, with 4 sample channels. I 
  67. don't think we need high frequency playback, as most of the Doom samples 
  68. are based around 8-16Khz. We should easily get away with 12kHz DMA. 25kHz 
  69. might have too much impact on the 
  70. display.
  71.  
  72.  d> Should we bother with the 
  73. music?
  74.  
  75. Probably not, unless somebody wants to take it on against all odds -without 
  76. a DSP or more than about 10% CPU time. 
  77. :)))
  78.  
  79.  d> With graphics moved over to the DSP, we might not be able to 
  80. use
  81.  d> that for any of 
  82. this.
  83.  
  84. Agreed. It is possible we could make the music/sfx switchable - 68040's or 
  85. 50Mhz 68030's shouldn't have a problem in the audio mixing 
  86. department.
  87.  d> - 
  88. AI
  89.  d> This is probably a lot more difficult than it appears at a 
  90. first
  91.  d> look. Is there an efficient way to give the monsters 
  92. 'sight'?
  93.  
  94. We have to be careful with this area - it has to be done right. The WAD 
  95. reject table will be helpful, but we have to remember that not all WADS 
  96. make use of it - some just fill the reject map with dummy 
  97. data.
  98.  
  99.  d> How about algorithms for monster movements and long range 
  100. attacks?
  101.  d> We'll need at least some very simple algorithms for these things 
  102. if
  103.  d> we're going to get a 'playable' game out before 
  104. Christmas.
  105.  
  106. Oh dear... deadline hassles already. 
  107. :)
  108.  
  109.  d> - player (and monster/missile) movement 
  110. restrictions
  111.  d> Nothing must be allowed to pass through walls, 
  112. naturally.
  113.  d> While this is not difficult to handle in principle, we'll 
  114. most
  115.  d> likely need some 'smart' way of doing 
  116. it.
  117.  
  118. It will probably end up based on convex polygon internal / external testing 
  119. using vectors, and perhaps discarding some of the walls which can't be seen 
  120. beforehand....
  121.  
  122.  d> - level 
  123. editing
  124.  d> Wouldn't it be nice to have a .WAD editor for the 
  125. Falcon?
  126.  
  127. Hmmmm. DEU shouldn't be that hard to port - and improve. It still gets its 
  128. rules wrong in places, and the nodebuilder is rubbish. 
  129. :)
  130.  
  131.  d> I'm sure I forgot several important things above, but at least 
  132. this
  133.  d> should be a start for 
  134. discussions.
  135.  
  136. We'll just have to take it as it comes - there's still so much to 
  137. do.
  138.  
  139. Doug.
  140.  
  141. ┌───────────────────────────────────────────────────────────────────────┐
  142. │  Black Scorpion Software Developments   ≡≡≡≡≡≡≡   Falcon030 & Jaguar  
  143. │
  144. ├───────────────────────────────────────────────────────────────────────┤
  145. │  Doug Little   ≡   Neil Stewart   ≡   Nick Hesketh   ≡   Dave Encill  
  146. │
  147. └───────────────────────────────────────────────────────────────────────┘
  148.  
  149. --
  150.  
  151.  
  152.